home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 760 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  6.0 KB
  1. Path: nntp.teleport.com!sschaem
  2. From: sschaem@teleport.com (Stephan Schaem)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: PPC compilers
  5. Date: 11 Jan 1996 11:52:57 GMT
  6. Organization: Teleport - Portland's Public Access (503) 220-1016
  7. Message-ID: <4d2tmp$o03@maureen.teleport.com>
  8. References: <john.hendrikx.40ka@grafix.xs4all.nl> <4ck47h$g07@maureen.teleport.com> <19960106.4EE928.CF59@sisyphus.demon.co.uk> <4cokkg$415@maureen.teleport.com> <19960107.533250.14585@sisyphus.demon.co.uk> <4cqrti$f6u@maureen.teleport.com> <19960109.55D920.1497F@sisyphus.demon.co.uk>
  9. NNTP-Posting-Host: kelly.teleport.com
  10. X-Newsreader: TIN [version 1.2 PL2]
  11.  
  12. Dave.Sparks@sisyphus.demon.co.uk wrote:
  13. : >>>>> "SS" == Stephan Schaem <sschaem@teleport.com> writes:
  14.  
  15. :   SS> Dave.Sparks@sisyphus.demon.co.uk wrote:
  16.  
  17. :   SS> I cant see how people can write code without knowing what data
  18. :   SS> or type they manipulate...
  19.  
  20. :   >> Real-world programmers do it all the time.  If you ever want to
  21.  
  22. :   SS> So you do math operation without knowing that your destination need
  23. :   SS> to be a float or a 2 byte int?
  24.  
  25. :   >> Yes.  This is a trivial example of polymorphism.
  26.  
  27. :   SS>  polymorphism?
  28.  
  29. :   SS>  int a,b,c;
  30.  
  31. :   SS>  ...  a = b /c; a *= result; ...  struct.float = a;
  32.  
  33. :   SS>  I dunno , I just find it puzzling to declar variable without giving
  34. :   SS> a care of what its usage will be. You programing practice is VERY
  35. :   SS> unwise...
  36.  
  37. : If I want to store a value of type clock_t, I declare a value of
  38. : type clock_t - knowing that it could be signed or unsigned int or
  39. : long, or float or double.
  40.  
  41.  Ok, you have to know its a type C can handle with its operator...
  42.  Now, what if you want to do some operation on the vague type, of
  43.  vague range? 
  44.  
  45. :  I guess I really have to spoon feed you a real life example.
  46.  
  47. :     clock_t start_time, end_time;
  48. :     double time_used;
  49. :     ...
  50. :     start_time = clock ();
  51. :     ...
  52. :     end_time = clock ();
  53. :     time_used = ((double) (end_time - start_time)) / CLOCKS_PER_SEC;
  54. :     ...
  55. :     printf ("Time used was %.3f seconds/n", time_used);
  56.  
  57.  When you write time_used, you know that time_used is a variable of
  58.  type double... you know that double is a real. You know that
  59.  end_time and start_time are of type clock_t and you know that type
  60.  clock_t is something you can use with C operators.
  61.  
  62.  I dont see in what you wrote where a C coder can forget his variable type
  63.  and type definition when he write compared to a asm programmer.
  64.  
  65. : is hardware-independent ANSI C.  Don't worry about the few
  66. : floating-point operations: anyone who is worried about performance
  67. : will have hardware which can execute floating-point ops
  68. : asynchronously.  If the C compiler does its job properly and
  69. : generates the instructions in the best order, the floating-point
  70. : ops will be executed in parallel and the total execution time may
  71. : even be _less_ than the time which would have been needed if
  72. : fixed-point had been used.
  73.  
  74.  I can worry alot.. even on 150mhz mips risc chips I use tables to do some
  75.  operation VS using int multiplication...
  76.  But in this I couldn't care if the float operation are execute by superslow
  77.  math function on a 68000.
  78.  The point is, you didn't write the example blindly... 
  79.  
  80.  BTW I never denied the advantage of having custom type... But realize that
  81.  when you code function in asm, there are pretty much system depandent.
  82.  My all point was about C and asm programming and the 'advantage' of C
  83.  programmer not having to know there variable type and type definition:
  84.  something I find unwise.
  85.  
  86. :   SS>  You said yourself after peeking at the .h that clock_t was
  87. :   SS>  a ulong.
  88.  
  89. : I didn't peek the .h , I read the docs.  And my code doesn't
  90. : depend on clock_t being unsigned long.
  91.  
  92.  then the doc will probably tell you that clock_t is system depandent,
  93.  is a type that is supported by C operators, and define its range and
  94.  function .
  95.  
  96.  the same info is avail for asm programmer... But he will have to use
  97.  the asm type VS the renamed type. I never said asm have type redefinition. 
  98.  
  99. :   >> target CPU?  How quaint ...
  100.  
  101. :   SS>  But target CPU is something that come up often in the real world of
  102. :   SS> programming... oh, forgot you think you are part of it.  C compiler
  103.  
  104. : If your product is a large, expensive program with a small niche
  105. : market, and your various potential customers use Amiga, SUN,
  106. : RS6000 or HP, you can't afford to target your code on a single
  107. : processor type.  You may have to write some parts of your program
  108. : in assembly code, either for performance or because some functions
  109. : can't be performed in C, but you'll be reluctant to do so because
  110. : the assembly code will have to be written and tested four times.
  111.  
  112.  Thats true... and I agree. This is also true for OS specific code,
  113.  at least once for each new machine you will work on. (I make a habbit
  114.  to never call the OS function directly)
  115.  
  116. :   SS>  The way you get optimal speed is optimizing the optimal algorithim.
  117. :   SS> If you stop at the algorithm you loose... Optimizing at this stage
  118. :   SS> will give an exponential result on the work you done on the
  119. :   SS> algorithm.  And usually this stage is done in assembler.
  120.  
  121. : Getting the algorithm right can improve performance by orders of
  122. : magnitude (i.e. not thinking about the algorithm can degrade
  123. : performance by a factor of ten or more).  Writing everything in
  124. : assembler might save 20% over writing everything in C and using a
  125. : good compiler.  Writing the bulk of your code in C and a small
  126. : proportion (less than 5%) in assembler is usually a good compromise.
  127.  
  128.  20% is way to low in the real world.. from 0 to 400% is more realistic.
  129.  
  130.  I only write pure asm code on the amiga when I know its only for the amiga,
  131.  and the algo are not overly complex.
  132.  
  133.  my latest stuff: 99% ansi C + mips asm (targeted only for low SGI box), C
  134.  only for W3.1 and macos 7.x (80% was portable the rest was OS specific), 
  135.  asm only for an amiga video driver for a mac emulator...
  136.  
  137.  If you want I give you the algo for the c2p in the mac driver and you write
  138.  a version that is only 20% slower? Its is no tricky code like addx, or swap
  139.  etc.. all the logic is portable to C.
  140.  
  141.  Stephan
  142.